1. Technical Field
The present invention relates to data protection in general, and particularly to a method for protecting an encryption key sent by a system to a disk drive within the system for reading encrypted data.
2. Description of Related Art
The field for information processing has always been struggling with the difficulty of protecting data stored in a hard disk drive (HDD) and/or a solid state drive (SSD) located within a computer. Microsoft Cooperation had provided a product called Windows® BitLocker® drive encryption that encrypts the entire volume of a disk drive as a whole.
Windows® BitLocker® is configured to write data encrypted by a processor of a computer system to a HDD of the computer system. Hereinafter, Windows® BitLocker® will be called software BitLocker®. Although a software BitLocker can eliminate the risk of data being eavesdropped through stolen HDDs or recycled computers, it takes many hours to perform an initial encryption, and the system performance will be degraded because of the encryption processing and decoding processing that are required for every data access.
In order to improve security techniques in computing environment, the Trusted Computing Group (TCG) released in 2012 the TCG Storage Security Subsystem Class: Opal “Specification Version 2.00” (TCG OPAL) as a specification for storage security. Since then, many vendors have provided hardware-based full disk encryption (FDE) disk drives complying with the TCG OPAL. FDE disk drives are configured to encrypt all data in a disk or a disk volume by an encrypting technique using hardware and device firmware mounted internally. The encryption is performed using a 128-bit or 256-bit Advanced Encryption Standard (AES) key.
Microsoft Corporation developed the specification of new BitLocker® incorporated into an operating system, which uses a HDD called eDrive complying with TCG OPAL and IEEE 1667, and started the implementation thereof in Windows® 8 operating system. Hereinafter such BitLocker® that performs encryption inside of a HDD will be called hardware BitLocker®. In hardware BitLocker®, the eDrive internally encrypts all data received from a computer system.
While the hardware BitLocker® has the advantage of having an excellent performance compared with the software BitLocker®, it has another problem of an encryption key being eavesdropped. The eDrive of the hardware BitLocker® encrypts data received from the system using a full volume encryption key (FVEK). This FVEK is encrypted by a volume master key (VMK) that the system has. The VMK is protected by a security chip called Trusted Platform Module (TPM) having the specification specified by the TCG, and so it is at a very low risk of being eavesdropped when the system holds the key.
In the hardware BitLocker®, in order to allow the eDrive to read encrypted data stored, the VMK has to be transferred to the eDrive to decode the FVEK. When the eDrive is a boot drive, the hardware BitLocker® has to transfer the VMK to the eDrive for decoding before loading of a boot file starts. The hardware BitLocker® set to enable transfers the VMK to the eDrive automatically during the boot routine. At this point, if an eavesdropper who has acquired the computer in an unauthorized manner inserts an eavesdropping device between the eDrive and a connector of a motherboard and starts the booting process, then the VMK that is automatically transferred by the system can be intercepted. Such a problem does not happen in the software BitLocker® because there is no need to transfer an encrypted key to the HDD.
There is a prior art method for preventing eavesdropping of a HDD password. When system firmware, such as BIOS and UEFI, returns from a suspend state or a hibernation state, if detachment of the disk drive from the main unit before that is detected, the software stops automatic transmission of a HDD password, and requests a user to input the password or forcibly shuts down the system to protect the password.
The above-mentioned prior art method for protecting a HDD password that a system firmware sends out cannot stop the automatic transmission of the VMK by the hardware BitLocker® even if insertion of an eavesdropping device can be detected. The hardware BitLocker® enables setting so as to request user authentication every time the FMK is sent. That is, eavesdropping can be prevented by setting user authentication by a password that the authentic owner of the computer only knows as the condition to transfer the VMK. Since the VMK is protected via the TPM, the eDrive detached and attached to another computer will fail to acquire the VMK with such a computer.
Requesting of a password every time the system boots or resumes from a sleep state, however, will unfavorably impair the quick returning of the computer. Further, password management will be burden for a user, and so the user may not set a password. In this case, protection using a password is practically difficult. Since the advantage of the hardware BitLocker® resides in automatic and transparent encryption of the volume as a whole, the VMK also has to be protected so as not to impair such an advantage. If the VMK can be protected by system firmware only that runs in secure environment of the computer, the protection will be reliable and the implementation can be facilitated, meaning that a protective function can be easily implemented in the computer.
Consequently, it would be desirable to provide an improved method for protecting an encryption key that is sent by a system to a disk drive within the system for reading encrypted data.